The testing of a processor is a time consuming and expensive process. Traditional testing of processor designs involves two types of testing: pre-silicon verification and post-silicon validation.
Pre-silicon verification involves running a simulation of the processor in a virtual environment to detect anomalies in the design. Often pseudo-random test generation is used to generate sequences of transactions at periodic intervals to re-create real-life traffic scenarios that the processor is likely to encounter. These pseudo-random tests may provide randomized coverage of the ISA (Industry Set Architecture) instruction set as well as processor modes, virtualization, privilege rings, system management and exceptions. However, pre-silicon verification tools do not provide the combination of sharp focus and intense permutation necessary to target specific internal features of the processor core. Instead, these tools use a massive number of random cycles while using internal coverage tools to tell when most of the internal nodes have been touched by the stimulus. Not only is this process incredibly slow, it is fundamentally limited by the rigid timing behavior of the virtual test environment.
Post-silicon validation involves operating the fabricated processor chips in actual application environments to validate correct behaviors over specified operating conditions. The objective of validation is to ensure that the product provides a targeted level of customer experience in terms of performance and function. Bug finding is not its primary goal. However, validation is limited in its ability to find bugs by the fact that actual application environments operate in repetitive and predictable ways. Diagnostic applications and random exercisers are sometimes used as a part of the validation process but these have significant liabilities. Diagnostics and exercisers are limited in their effectiveness by their need to perform data integrity self-checking as a pass/fail metric. This puts a tremendously restrictive burden of rules on how tests can function in a multi-processing environment. As a result, these data coherency and sharing rules limit the permutation space that is critical for finding functional bugs in the design.
Bugs and errors in the design of the processor cause undesirable behaviors in the computer in which they are installed. For example, a bug in the processor may result in a deadlock, exceptions, stalls and data integrity failures. When a deadlock occurs in a computer utilizing the processor, the computer must be restarted, and all of the user's unsaved data is likely lost. When a bug-induced exception occurs, it may result in immediate termination of the user's application or a crash of the operating system, both of which are likely to result in a loss of data and a loss of service of the computer. Similarly, when other bug-induced exceptions and stalls occur, the computer is slowed down as additional computer resources are required to address the faults. In addition, data integrity failures may allow incorrect data to be written to a user's files or database. This may pose a security vulnerability of the computer as the data integrity failure may be exploited to access secure data on the computer.
There exists a need for a method of efficiently identifying bugs resident in a fabricated processor that is not limited by the restrictions found in the prior art. As a result of identifying the bugs in the fabricated processor, the design of the processor can then be improved to no longer produce the identified bugs and therefore improve the operation of the computer in which the processor is installed.